Libris Britannia 4/science library(b).zip/science library(b)/INFO/DOSTIPS.ZIP/DOSTIPS1.TXT

Text File | 1987-12-14 | 13KB | 228 lines

                           MS-DOS_Tips


Hi Folks!

I'd  like to share some of my time-saving tips in MS-DOS.   Since
being  introduced  to the operating system some  time  ago,  I've
spent  many hours attempting to develop ways to save  time  while
programming.   Programming  involves the use  of  every  resource
available from your PC.  When I refer to "PC" I am addressing any
MS/PC-DOS  compatible computer.  The Public Domain has to be  the
most informative source of ideas I have ever come across.  I will
have to admit that 50% of my programming conceptions originate in
the PD.  I contribute to the PD as much as the next guy so I feel
using  the  resource  is  permissible.   My  point  is  that  for
information and examples to follow, the PD is the place to  look.
The electronic bulletin board network is the best source for  PD.
With  the low cost of modems and the availability  of  incredibly
feature-packed  modem programs in the PD (read: free), I  see  no
reason not to plug in to the resource gold mine.  Unless you only
occasionally  use your PC for applications programs only,  GET  A
MODEM!

Throughout this article I will refer to MS-DOS synonymously  with
PC-DOS.   Also, all references are to my Kaypro 286i system.   My
drives  are  configured  as follows.  A and B  are  1.2  megabyte
floppies.   C  and D are 21.5 megabyte hard disks.  Some  of  the
procedures  outlined  below may not be suitable for  360K  floppy
based  systems.  I do also use all the procedures outlined  below
on my Kaypro 16.  A and B are 360K floppies.  C is a 10  megabyte
hard  disk.   I think the Kaypro 16 is the most  popular  of  the
pseudo-16 bit Kaypro systems so the procedures will apply to it.

MS-DOS has this great built-in facility called batch  processing.
In the old days (two years ago?) batch processing referred to the
use  of a main-frame computer in slices of time.   All  processes
needing CPU time were bundled together on punch cards and all fed
in  at  one time.  They were  sequentially  processed  generating
corresponding  output  or files and then the next member  of  the
batch was processed.  There was no benefit of interactive use  of
the  computer.   You had one chance to get it right or  else  you
resubmitted  the  whole  batch  again the  next  day.   With  the
introduction of the personal computer, interactive utilization of
the  machine is possible.  But with all this technology, we  find
ourselves in redundancy sometimes.  There is a way out.

Many sequences of commands are used daily by the operator in  MS-
DOS  that can be batched together.  There are two simple ways  to
create  a batch file.  One is to use a text editor.  I use  EDLIN
just  because of it's simple command set and small size and  fast
speed.  Believe me, it's not much of an editor for anything  more
than  that.  The other way is by device redirection.   Here's  an
example:
     C:
     CD \FRED
     MARTHA

If  you  entered  this  list  of  commands  into  a  file  called
HARRY.BAT, every time you typed HARRY at the DOS command  prompt,
the  COMMAND.COM  resident  processing  system  would  read   the
commands  from this file one line at a time.  First we would  log
into  drive C.  Then change to the directory on that drive  named
FRED.   Now the system would run a program named MARTHA.  If  you
include  a program name after MARTHA, then as soon as  MARTHA  is
through  running,  the COMMAND.COM processor remembers  you  have
another command to execute and will do just that.  You can string
these  things out as far as you want.  In fact, you can  use  the
COMMAND /C command to load another COMMAND.COM processor and  use
the DOS commands in it just like before.  Now as soon as you type
EXIT at the DOS prompt, the first COMMAND.COM processor will take
over  and  execute  the remaining commands.   I'll  give  you  an
example:
     C:
     CD \FRED
     MARTHA
     COMMAND /C
     WP

Suppose  you  have  a file called DO-IT.BAT  on  your  disk.   It
contains  the list of commands shown above.  Typing DO-IT at  the
DOS prompt will log into drive C, change directory to FRED, run a
program  called  MARTHA and as soon as MARTHA  was  finished  you
would  see a DOS prompt.  You are not really where  you  started.
You  are  now  within a second DOS command  processor.   You  can
execute  any DOS command you want.  Now as soon as you  type  the
command EXIT, you are returned to the first command processor and
it  will pick up where it left off, executing the program  called
WP.  This was a case of "nesting" the command processor.  In CP/M
the equivalent of the command processor is called the CCP.   ZCPR
was  a great attempt to help the user in CP/M to accomplish  some
of the tasks available in DOS.

The  second  method of generating a batch file is  called  device
redirection.  It's really a quite fast economical way to generate
any  small file.  DOS treats everything it is connected to  as  a
device.  The CRT, keyboard, disk drives, serial port etc. are all
devices to DOS.  You have the ability to copy files, or  actually
any data string, to and from the different devices.  You probably
already know that any time you append a ">PRN" to a command,  all
output  from the command is redirected to the printer.   You  can
redirect  to  a file also.  ">FRED" appended to a  command  would
send  all output from the command to a file called FRED.  If  you
want to add (append) stuff to the end of an already existing file
just use two ">"'s.  As in TYPE FILENAME.EXT >>FRED.  This  would
send all printable characters sent to the screen to the end of an
existing file named FRED.  These examples of I/O redirection  are
fairly  popular and documented.  One type of redirection  is  all
too  often  ignored.  COPY CON is a form of redirection  that  is
handy  in  creating  small batch files.  If you  type  "COPY  CON
FRED.BAT"  all  keys typed on the keyboard and generated  on  the
screen  will  be  sent to a file named FRED.BAT.   You  have  now
created  a batch file.  The return key will generate  a  carriage
return  character in the file.  To end the redirection and  close
the file use the end-of-file character CTRL-Z.  You can hold down
the  CTRL  key  or use the F6 function  key.   Actually  all  the
command accomplished was the copying of one devices output  (CON)
to  another  device. (in this case the other device  was  a  file
named FRED) (Is that anything like a boy named Sue?)

DOS users will tell you that there is one thing batch files  will
not accomplish; the ability to run another batch file, then after
it is finished, return to the originating batch file to  continue
processing.  AHA!  Not true.  You can execute another batch  file
as a "subroutine".  A subroutine, as defined in the Mike Stickney
Fanatic Programmer's Manual, is a procedure, function or complete
program called from another procedure, function or program; after
which  a  return is made to the calling  procedure,  function  or
program.  In other words, do something and come back when  you're
finished.   If you use the COMMAND /C with a batch filename,  DOS
will  load another command processor, execute the batch file  and
as  long as the batch file has an EXIT command in it,  return  to
the  point in the originating batch file after the  last  command
issued.   The  syntax  (no, not a tax on sex,  but  the  required
spelling,  etc.) of the command is "COMMAND command  /C".   Where
"command" is any DOS command or batch filename.  Just remember to
put the EXIT command in the called batch file.

Here's  a tricky one.  Have you ever wanted to have a batch  file
go  to  another  directory, issue a command, and  return  to  the
directory  area that it was called from?  Sure, you could  put  a
"CD  \directory"  command  at the end of the  batch  file.   What
happens when you call this batch file from another directory?  If
your path is set properly, IE: multiple paths of which one points
to the directory area where all your batch files are stored,  you
can  call  your batch files from ANYWHERE in ANY disk  drive.   I
figured out a way to accomplish a return to the calling directory
area.   (I'll  admit I saw an article in the latest  PC  magazine
that accomplishes this in a manner similar to mine, but I figured
out  mine first!)  First I'll list the batch commands below  that
accomplish this.  The commands are in a file named SAVDIR.BAT.

     DEL C:\BAT\RETDIR.BAT >NUL
     COPY C:\BAT\CD.TXT C:\BAT\RETDIR.BAT >NUL
     CD >>C:\BAT\RETDIR.BAT
     EXIT

This  list assumes a file already exists in C:\BAT named  CD.TXT.
CD.TXT contains the characters "CD ".  I have my directory search
path set up as follows:

     PATH=C:\DOS;C:\BAT;C:\;C:\NORTON;C:\UTILITY;C:\WP;D:\MOUSE

As  you can see, I have a path set to my C drive \BAT  directory.
My \BAT directory contains all my batch files.  This way whenever
I  need a batch file I need only type the batch command  name  at
the  prompt.  DOS will search along the paths for  the  directory
containing  the batch file.  This might get a little  complex  so
please read this a few times until you understand it.

The only other thing you need is the awareness that when you want
the batch file to return to the calling directory area, you issue
the  command RETDIR.  Now I'll outline what all this  mess  does.
This  refers  to  the four line batch  file  listed  above  named
SAVDIR.BAT.

Line  1)  Delete any file in the \BAT directory on  the  C  drive
named  RETDIR.BAT.  This gets rid of any RETDIR batch  file  left
over from the last use.

Line  2)  Copy  the contents of CD.TXT ("CD ") to  a  file  named
RETDIR.BAT.   The  >NUL on the end sends all output  to  the  NUL
device.   The  NUL device is just like it  sounds,  meaning  send
output to never-never land.  In other words, don't clutter up the
screen with crap when you don't have to.  Otherwise you'll see "1
file(s) copied" and this might be confusing.

Line  3) Issue a CD command and append the output to the file  we
created above.  Issuing CD by itself will cause DOS to print  out
the curent disk and directory.  Since we redirected the output to
the  RETDIR.BAT file, now we have a command in a batch file  that
will take us back to where we originated.  All references to  the
files  have  their full paths preceding them so  the  files  will
always  be found in the same place.  The issuance of the  command
"RETDIR"  will  cause the RETDIR.BAT file to  be  executed  which
contains the command we need.

Line 4) EXIT back to the originating command processor.

The  only  thing you need be aware of at this point is  that  the
SAVDIR   command  must  be  executed  as  a  child   process   of
COMMAND.COM.   In  other  words  we need to  run  SAVDIR  like  a
subroutine  so  that when the SAVDIR batch file is done,  we  are
returned  to the originating batch file that has the commands  we
needed to process in the first place.  This is done as  described
earlier.  "COMMAND SAVDIR /C".  I have found one limitation  with
this process.  It will not change the logged disk drive.  If  you
call  this  procedure  from  drive D and  the  commands  you  are
executing  take you to drive C, you will remain in drive C.   Now
the SAVDIR/RETDIR stuff hasn't completely been wasted.   Whenever
you  issue the CD command specifying a different disk drive,  the
"default"  directory  on the drive will be changed  to  what  you
specify.   Remember, when you type CD all by itself  DOS  outputs
the drive and directory presently occupied.  Since we use the  CD
command to generate our RETDIR batch file, the command  generated
will  contain the disk drive prefix.  If all our  batch  commands
keep  us  in the same drive, we're okay.   Changing  the  default
directory of the drive you are presently logged into is the  same
as logging into that directory.  If you do use this procedure  to
migrate  from drive to drive, all you have to do after the  batch
file  is done is change drives.  The originating  directory  area
will be the one you are automatically dropped into.

As  you can see, you can make batch file processing as simple  or
as  complex as you want.  With all the commands available to  you
at  the  DOS  prompt, you really have  a  whole  new  programming
language suitable for minor housekeeping chores.

                                      Mike Stickney, SYSOP - SKUG